REMARKS 



1 . Summary of the Office Action 

In the Office Action mailed July 7, 2009, the Examiner rejected claims 65-88 under 35 
U.S.C. 102(e) as being anticipated by U.S. Patent No. 6,175,789 ("Beckert"). 



2. Status of the Claims 

Applicant has amended claim 65, 68, 69, 72-74, 77, 82-83, and 85-87. Further, 
Applicant has canceled claim 66. Applicant respectfully submits that claims 65 and 67-88 are in 
condition for allowance and respectfully request notice to this effect. Of these claims, claims 65 
and 81 are independent. 



3. Response to Rejections 

As noted above, the Examiner rejected claims 65-88 under 35 U.S.C. 102(e) as being 

anticipated by Beckert. Applicant has amended claim 65 to include the substance of claim 66, 

and thus Applicant has canceled claim 66. Further, Applicant has amended claim 81 to include 

elements similar to the subject matter of claim 66. 

A. The Beckert Reference fails to disclose "authenticating devices connected 
to the AMI-C bus . . . wherein authenticating devices . . . comprises ... if 
the device is not authorized, instructing the port node to prevent any traffic 
from the unauthorized device from being passed from the device to the 
AMI-C bus" 

As explained in the response to the Office Action mailed January 16, 2009 (filed April 13, 
2009) and the response after the Final Office Action mailed July 7, 2009 (filed September 8, 
2009), claim 65 recites a method including "authenticating devices connected to the AMI-C bus 
at the gateway device using an application processor" and claim 81 recites a gateway device 
including an "application processor . . . adapted to (i) authenticate AMI-C devices connected to 
the AMI-C bus." Applicant maintains that Beckert fails to disclose these elements. 

In addressing Applicant's argument that Beckert fails to disclose "authenticating devices 
connected to the AMI-C bus," the Examiner cited to column 7, lines 20-60 of Beckert in both the 
Response to Arguments section of the July 7, 2009 Office Action and the Advisory Action 
mailed November 10, 2009. Applicant respectfully disagrees that this cited portion of Beckert 
shows or suggests authenticating devices connected to the AMI-C bus. The Applicant notes 
that the Examiner did not offer an explanation as to why or how this cited portion of Beckert 
discloses authenticating devices connected to the AMI-C bus in either the Final Office Action 
mailed July 7, 2009 or the Advisory Action mailed November 10, 2009. However, a detailed 
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review of the cited sections reveals that the cited section is completely silent as to 
authenticating devices connected to the AMI-C bus. 

For clarity, the entire section cited by the Examiner is reproduced below: 

The security system 146 is connected to actuators which lock/unlock 
doors and windows, and to an alarm which can be activated upon 
detection of unwanted tampering. An OBD (On Board Diagnostic) 
interpreter 128 is provided in the computer module to communicate with 
the OBD system built into the vehicle by the manufacturer. The OBD 
interpreter 116 interprets the status data received and provides 
performance related information from the vehicle's OBD system to the 
microprocessor 100. Also, commands can be provided to the interpreter 
which allows non-critical car systems to be controlled. 

A more detailed explanation of the three modules in the vehicle computer 
system is provided in co-pending U.S. patent application Ser. No. 
08/564,586 entitled "Vehicle Computer System," which was filed on Nov. 
29, 1995 in the names of Richard D. Beckert, Mark M. Moeller, and 
William Wong. This application is assigned to Microsoft Corporation and 
is incorporated herein by reference. 

The logic unit 90 within the support module 62 is configured with its own 
multi-bit bus structure that is separate from the bus of the microprocessor 
130 of the computer module 64. The logic unit 90 and microprocessor 
130 are interfaced using a bus, such as PCI bus 66. By configuring the 
logic unit 90 with its own bus, the logic unit 90 is capable of better 
performing its tasks independent of intervention from the microprocessor 
130. Moreover, the internal bus of the logic unit 90 facilitates data 
communication between the audio components and other serial devices 
while using minimal processing resources of the microprocessor 130. 

FIG. 4 shows a preferred implementation of an internal bus structure 140 
of the logic unit 90 of the support module and the interface between the 
internal bus 140 and external devices. The internal multi-bit bus structure 
140 includes an address bus 142, a data bus 144, and a control bus 146. 
In the illustrated implementation, the data bus 144 is a 32-bit bus and the 
address bus 142 is a sufficiently large to support in parallel at least 19 
address bits, such as through a 32-bit bus. The busses are tri-state 
busses which are driven by one of several sources. An internal bus 
arbiter 148 determines which device is in control of the bus structure 140. 
At no point does this cited section deal with authenticating devices connected to an AMI- 
C bus. Applicant recognizes that the first paragraph of this section discusses a security system 
connected to an alarm which can be activated upon detection of unwanted tampering. (See 
column 7, lines 20-23.) Thus, Beckert discloses a security system, but this security system 
does not authenticate devices connected to an AMI-C bus. Rather, the security application of 
Beckert monitors security sensors 26 for any potential threat of theft or vandalism. (See, 
column 7, lines 16-19.) However, this described security function is different than providing 



McDonnell Boehnen Hulbert & Berghoff, LLP. 8 Serial No. 09/680,608 

300 South Wacker Drive Attorney Docket No.08-880-US12 
Chicago, IL 60606 

(312)913-0001 Filing Date. October 4, 2000 



security for devices connected to or connecting to an AMI-C bus. Significantly, there is no 
disclosure or suggestion of the security system authenticating devices connected to an AMI-C 
bus. 

The remaining cited portions do not even deal with security, much less providing security 
functions for an AMI-C bus, such as authenticating devices connected to the AMI-C bus. For 
example, column 7, lines 23-30 discloses an On Board Diagnostic (OBD) Interpreter that can 
receive commands to allow for non-critical car systems to be controlled. Further, column 7, 
lines 38-49 deals with details regarding logic unit 90 within the support module 62 that is 
separate from microprocessor 130. The logic unit is capable of performing tasks independent of 
intervention from the microprocessor because the logic unit is configured with its own bus. Still 
further, column 7, lines 50-60 discusses a multi-bit bus structure 140 that includes an address 
bus, a data bus, and a control bus. However, these disclosures of the OBD interpreter, logic 
unit 90, and the multi-bit bus structure 140 clearly do not amount to disclosures of 
authenticating devices connected to an AMI-C bus. In light of the above, it is clear that this 
cited section of Beckert does not disclose what the Examiner asserts that it does. 

Applicant also recognizes the above cited section incorporates by reference co-pending 

U.S. patent application Ser. No. 08/564,586 entitled "Vehicle Computer System," (now U.S. 

Patent No. 5,794,164 and hereinafter referred to as "Beckert 2"). Beckert 2 also fails to disclose 

authenticating devices connected to an AMI-C bus. To the extent that Beckert 2 deals with 

authentication, the authentication is only in the context of a vehicle security system. In 

particular, Beckert 2 states: 

The computer module 64 also includes at least one flat panel display 
controller 1 18 to control the flat panel monitor 24. A dual PC card socket 
44 is provided to support 2-type II or 1-type III PC cards. Such cards 
might be configured as extra memory, moderns, network adapters, or 
other components. The computer module 64 also has a smart card reader 
42 which accepts smart cards (i.e., plastic cards with an integrated circuit 
mounted thereon). The smart cards can be programmed as a key to the 
vehicle, to contain encrypted driver identification that the security system 
uses to authenticate the driver before the vehicle can be started, and be 
programmed to remember vehicle driver configuration profiles. In the 
event the microprocessor does not recognize the identification on the 
smart card, the security system can activate the alarm or take other 
precautionary measures to prevent theft by unauthorized users. For 
added security, a driver might also be asked to input a PIN (personal 
identification number) using the keypad 52 on the faceplate. (Beckert 2, 
column 9, lines 36-54) 
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However, this authentication disclosed in column 9, lines 36-54 is not an authentication 
of devices attempting to connect to an AMI-C bus. Rather, in Beckert 2, a smart card reader 
reads an inserted smart card, and then the vehicle's security system determines whether the 
instered smart card is an authorized smart card. However, this described security function is 
different than providing security for devices connected to or connecting to an AMI-C bus. 
Significantly, there is no disclosure or suggestion of the security system authenticating devices 
connected to an AMI-C bus. 

Nonetheless, Applicant has amended claims 65 and 81 to clarify that "authenticating 
devices connected to the AMI-C bus at the gateway device using an application processor 
comprises: consulting a security database to determine whether a device attempting to access 
the AMI-C bus via a port node is authorized to communicate with the AMI-C bus; and if the 
device is not authorized, instructing the port node to prevent any traffic from the unauthorized 
device from being passed from the device to the AMI-C bus." Applicant respectfully submits 
that neither Beckert nor Beckert 2 disclose "if the device is not authorized, instructing the port 
node to prevent any traffic from the unauthorized device from being passed from the device to 
the AMI-C bus." 

In the final Office Action mailed July 7, 2009, in rejecting claim 66 (the substance of 
which has been incorporated into both claims 65 and 81), the Examiner cited to Beckert, column 
7, lines 21-31 for the teaching of "if the device is not authorized, instructing the port node to 
prevent any traffic from the unauthorized device from being passed from the device to the AMI- 
C bus." (Final Office Action, page 3.) In particular, column 7, lines 21-31 states: 

The security system 146 is connected to actuators which lock/unlock 
doors and windows, and to an alarm which can be activated upon 
detection of unwanted tampering. An OBD (On Board Diagnostic) 
interpreter 128 is provided in the computer module to communicate with 
the OBD system built into the vehicle by the manufacturer. The OBD 
interpreter 116 interprets the status data received and provides 
performance related information from the vehicle's OBD system to the 
microprocessor 100. Also, commands can be provided to the interpreter 
which allows non-critical car systems to be controlled. 
However, this cited section provides no disclosure of instructing the port node to prevent 
any traffic from the unauthorized device from being passed from the device to the AMI-C bus if 
the device is not authorized to connect to the AMI-C bus. 

Applicant also respectfully submits that Beckert 2 does not provide any disclosure of 
instructing the port node to prevent any traffic from the unauthorized device from being passed 
from the device to the AMI-C bus if the device is not authorized to connect to the AMI-C bus. As 
discussed above, Beckert 2 does not disclose authenticating devices connected to an AMI-C 
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bus. Further, there is no indication that the Beckert 2 system instructs a port node to prevent 
any traffic from an unauthorized device from being passed from the device to the AMI-C bus if 
the device is not authorized to connect to the AMI-C bus. Rather, at best, Beckert 2 discloses 
activating an alarm or taking other precautionary measures to prevent theft of the vehicle when 
an unauthorized smart card is inserted. (See, e.g., Beckert 2, column 9, lines 48-51.) However, 
Beckert 2 does not disclose "instructing the port node to prevent any traffic from the 
unauthorized device from being passed from the device to the AMI-C bus." Importantly, since 
there is no indication that the smart card or smart card reader is connected to or in 
communication with an AMI-C bus, Beckert 2 cannot - and does not — disclose instructing the 
port node to prevent any traffic from the unauthorized device from being passed from the device 
to the AMI-C bus. 

Because Beckert and Beckert 2 do not show or suggest authenticating devices 
connected to the AMI-C bus, Beckert and Beckert 2 do not show or suggest every element of 
claims 65 and 81. Accordingly, Applicant submits that Beckert and Beckert 2 do not anticipate 
claims 65 or 81 for at least this reason. Further, because Beckert and Beckert 2 do not show or 
suggest that "authenticating devices connected to the AMI-C bus . . . comprises ... if the device 
is not authorized, instructing the port node to prevent any traffic from the unauthorized device 
from being passed from the device to the AMI-C bus," Beckert and Beckert 2 do not show or 
suggest every element of claims 65 and 81. Accordingly, Applicant submits that Beckert and 
Beckert 2 do not anticipate claims 65 or 81 for at least this reason. 

Furthermore, claims 67-80 and 82-88 depend from claims 65 and 81, respectively. 
Accordingly, Applicant submits that Beckert and Beckert 2 do not anticipate claims 67-80 and 
82-88 for at least these same reasons described above with reference to claims 65 and 81 . 

In light of the above, Applicant respectfully requests withdrawal of the rejections under 
35 U.S.C. § 102(e). 
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4. Conclusion 

In view of the foregoing, Applicant submits that all pending claims are allowable, and 
thus Applicant respectfully requests allowance of these claims. Should the Examiner wish to 
discuss this case, the Examiner is invited to call the undersigned at (312) 913-3350. 



Respectfully submitted, 

McDonnell boehnen 
hulbert & berghoff llp 

Date: December 7, 2009 By: /Scott. M. Miller/ 

Scott M. Miller 
Registration No. 62,967 
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